動くスケルトンから始めよう

アリスター・コーバーンが「動くスケルトン」と呼んでいるものを出発点にすると、アーキテクチャーを実装、検査し、発展させていくための優れた戦略となります。動くスケルトンとは、アーキテクチャー上重要なコンポーネントをすべてリンクした最小限の完結した実装です。すべての通信路を備えた小さなシステムからスタートすれば、正しい方向に向かっているという自信が得られます。

スケルトンを作ったら、筋力養成プログラムを開始します。全身運動で身体を鍛えていくのです。これは、完結性を維持したまま新しい機能を少しずつ追加していくということです。目標は、スケルトンを成長させながら、システムを動かし続けることです。

アーキテクチャーが作られてから時間がたち、大きくなればなるほど、アーキテクチャーに変更を加えるのは難しく、コストのかかる仕事になっていきます。ですから、誤りは早い段階で見つけておきたいのです。動くスケルトン方式なら、フィードバックサイクルが短くなります。サイクルが短ければ、素早く適応し、同じ部分に繰り返し修正を加えることができます。顧客が優先的に必要とする品質性能は、自分でシステムを動かしてみなければわからないものですが、そのような品質を確保するためには、このような繰り返し作業が必要不可欠なのです。アーキテクチャーに含まれる暗黙の前提も、早い段階でチェックできます。実装にあまり時間をかけていない段階で問題点が見つかるので、アーキテクチャーを拡張していくのも簡単になります。

システムが大きくなればなるほど、この戦略は重要になってきます。小さなアプリケーションであれば、上から下まですべての機能を1人のデベロッパーが実装していけますが、大規模なシステムではそういうわけにはいきません。1つの完結した実装のために、複数のデベロッパーで1つのチームを組むのはもちろん、複数の分散化されたチームを組むことさえごく普通にあります。人数が増えれば、デベロッパー間での調整作業も増えます。そして当然ながら、デベロッパーによって実装のペースが違います。短い時間に多くの仕事をこなせるデベロッパーもいれば、時間をかけてもごくわずかしか実装できないデベロッパーもいます。時間がかかる難しい仕事は、プロジェクトの初期の段階で済ませておかなければなりません。

動くスケルトンからスタートし、動く状態を保ちながら、それを少しずつ育てていくのがコツです。